Messaging protocol for processing messages with attachments

ABSTRACT

A message that is to be processed according to an electronic messaging protocol is associated with a sender of the message. The message also includes an attachment from an attaching entity. The attachment is associated with a unique property of the attaching entity. Other embodiments are also described and claimed.

RELATED MATTERS

This application is a continuation of pending U.S. application Ser. No.12/196,638, filed Aug. 22, 2008, entitled “Messaging Protocol forProcessing Messages with Attachments, which is a continuation of U.S.patent application Ser. No. 10/851,311, filed May 21, 2004, which issuedas U.S. Pat. No. 7,421,514, on Sep. 2, 2008.

BACKGROUND

An embodiment of the invention is related to electronic messagingprotocols for a set of data networks that are interconnected withrouters (e.g., the Internet), and in particular to the processing ofmessages having attachments. Other embodiments are also described andclaimed.

Electronic messaging protocols such as those that are used to passmessages over the Internet are in widespread use. Examples of suchprotocols include electronic mail (email), news, and online-chat(sometimes referred to as Instant Messaging) protocols. These protocolstypically define a message as some form of data structure that has (i) amessage body and (ii) one or more header fields. The header fields maycontain information about where the message came from (e.g., the “from:”field of an email message), where it is going (e.g., the “to:” field ofan email message), its subject, when it was sent, etc. The message bodyon the other hand may contain the body or essence of the message, in theform of data that typically has a predefined format (e.g., consists onlyof ASCII characters).

Some protocols allow a sender to enclose or “attach” in the message bodyan object that is not in the predefined format. These protocols canautomatically translate between the predefined format and some otherformat used by a given software application (e.g., between 7-bit ASCIIcharacters and 8-bit binary characters). The attached objects may be“detached” by the recipient of the message, using the translationprotocol. For example, with respect to email messages, the MultipurposeInternet Mail Extensions (MIME) protocol allows non-ASCII objects suchas image files, audio/video files, and application software files (e.g.,word processor, spreadsheet, and database program files) to becomeattachments in a message. Attachments are represented to a user on adisplay monitor as, for example, a small icon together with anidentifier such as its filename.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments of the invention are illustrated by way of example andnot by way of limitation in the figures of the accompanying drawings inwhich like references indicate similar elements. It should be noted thatreferences to “an” embodiment of the invention in this disclosure arenot necessarily to the same embodiment, and they mean at least one.

FIG. 1 depicts a screen shot of a received email message with anassociated attachment.

FIG. 2 shows a conceptual diagram of a central server messaging systemin which an embodiment of a messaging protocol described here may beimplemented.

FIG. 3 shows a conceptual diagram of another environment for themessaging protocol in which message transfer agents and user agents areused.

FIG. 4 is a conceptual diagram of communications between the source andthe recipient in which the client programs are aware of the associatedattachment capability.

FIG. 5 depicts a conceptual diagram of communications between the sourceand the recipient where the client programs may be arbitrary in thatthey need not be aware of the associated attachment capability.

FIG. 6 illustrates a mouse-over feature for displaying information aboutan associated attachment.

FIG. 7 illustrates a collapse-down/collapse-up feature for displayinginformation about an associated attachment.

FIG. 8 shows a user interface screen shot that depicts an exampledefault view of a message, with a collapsed attachment section.

FIG. 9 shows a screen shot of the user interface in FIG. 8 with theattachment section expanded.

DETAILED DESCRIPTION

The inventor has noted that when a forwarded message has been receivedthat contains an attachment, conventional techniques do not show orsuggest to the recipient of the message who, among the various sendersassociated with the forwarded message, is the attaching entity. Forexample with respect to email, when an email message has been receivedthat has been forwarded at least once and that contains an attachment,the recipient has no indication which of the two or more previoussenders of the message actually requested that the attachment beinserted. Such information would be useful particularly in situationswhere a group of people are collaborating on one or more documents usingconventional email capabilities to pass different versions of thedocument as attachments.

According to an embodiment of the invention, an attachment within amessage (that is to be processed according to an electronic messagingprotocol) is associated with a unique property of the attaching entity.This is, of course, in addition to associating the message with asender. The method may be applied to multiple attachments, as well as tomessages that have been either newly created or have been forwarded morethan once, to more easily allow the recipient of the message todetermine who attached what to the message. A graphical user interfacemay then display not only an attachment name for each of the attachmentswithin a message, but also any unique property of the attaching entity(e.g., name, email address, etc.). This could be done for multipleattachments in the message, and one or more different attaching entitieswithin a single or recursive thread of a message chain.

As an example, consider that John Doe creates a message and attaches afile named “a.doc”. The message is then sent to Jane Smith, who receivesthe message and attaches another file named “b.doc”. The message is thenforwarded to Alice Cooper. When Alice receives and opens the messageusing, for example, a client program that supports such a methodology,or a Web interface with similar support, Alice would be presented withnot only a message with two attachments in a conventional sense, butwill also be presented with the name or other unique property of theperson that is directly associated with each attachment. Thus, in thisexample, Alice would see an attachment icon for a.doc, next which “JohnDoe” would be displayed. In addition, Alice would see an attachment iconfor b.doc, next to which “Jane Smith” is shown. See FIG. 1 for a furtherexample, where a screen shot of a window from a client program acting asa Web interface to an email box enhanced with the “associatedattachment” feature is shown. In this example, the display shows a“from” field 10 and a “to” field 14 for the most recent leg of aforwarded message. In addition, an earlier leg is also shown with “from”field 18 and “to” field 22. At the bottom of the screen are twoattachments that can be identified by their filename fields 26, 34. Eachof these is an “associated attachment” in that an additional field 30,38 has been added to more easily indicate to the email recipient theattaching entity. More generally, however, as described below, theassociated attachment technique may be applied to other types ofmessaging protocols, as well as other types of data communicationnetworks.

Turning now to FIG. 2, an example data network for implementing theassociated attachment capability is shown. In this example, themessaging protocol uses a single message server 108 in a central servermodel to pass messages between a number of connected user systems. Anexample message 120 originates with user system 116 (source) and is tobe delivered to the intended recipient at user system 104. The message120 may be stored within a central message store 112 under control ofthe message server 108, until a client program in the user system 104 isavailable to read the message. The message 120 includes an attachment124 that may have been inserted at the user system 116, a sender field125 which is filled with data that identifies the sender, a recipientfield 126 that identifies the recipient and an associated attachment(AA) field 128 that identifies the entity that requested that theattachment 124 be inserted. The message 120 so created is then storedwithin the central message store 112 on behalf of the recipientidentified in the recipient field 126.

Referring now to FIG. 3, another embodiment of the invention is shownwhere the messaging protocol operates over multiple networks that areinterconnected with one or more routers (e.g., the Internet). Here,rather than having a single message server 108 that serves all of theusers in the system, multiple systems or networks are connected withmessage transfer agents 204. In this case, a message 220 may originatewith a user agent 208 and will include one or more attachments 124together with their AA fields 128 as shown. The message 220 may bestored somewhere along the path between the source user agent 208 andthe destination user agent 212. Accordingly, there may be multiple“hops” between the source user agent 208 and the destination user agent212. As in the embodiment of FIG. 2, the intended recipient will receiveinformation about a message that has been processed according to anelectronic messaging protocol, where the message includes an attachmentfrom an attaching entity, a field to identify a sender of the message,and an AA field to identify the attaching entity. This information maybe taken from the different portions of the message 220 and may bedelivered either in one transfer or in separate transfers, to therecipient at the user agent 212.

Still referring to FIG. 3, the movement of messages from one system toanother, that is from one message transfer agent 204 to another, may beimplemented using server software that collects messages from a useragent 208 and passes them along to a destination message transfer agent206. As an example, the Simple Mail Transfer Protocol (SMTP) may be usedto define how a message is moved from one store or a file system toanother, or from one server to another.

A message may be sent from a user agent 208 to the server in messagetransfer agent 204, or from the server in message transfer agent 206 tothe user agent 212, using for example the Post Office Protocol (POP). Insuch a case, client software (or the user agent) for the recipientchecks the recipient's email box or message store every so often, to seeif any messages are there. If so, the message is downloaded and storedlocally to be subsequently presented to the recipient. Similarly, at thesource or sender site, it is client software or user agent 208 thatsends a message to a server in the message transfer agent 204 fordelivery.

FIG. 4 is a conceptual diagram of communications between the source andthe recipient in which the client programs (or simply, clients) 404, 420are aware of the associated attachment capability. In this embodiment, asource client 404 is referred to as being “AA aware” because it can notonly insert an attachment into a message that is to be sent, but it alsohas knowledge of and is able to insert and fill a new field of themessage, to identify the user of the source client 404 as the entity whorequested that the attachment be inserted.

Note that this message may be a newly created one, that is newly createdin the client 404, or it may be a forwarded message, that is, based onone previously received by the client 404 and that includes informationidentifying one or more prior senders. In the case of forwarded messagestherefore, a further attachment from a prior sender may be included inthe message, along with information that separately identifies the priorsender as a further attaching entity that inserted the furtherattachment. See, for example, the screen shot of FIG. 1 showing such aforwarded message with multiple attachments. Here, the informationidentifies the attaching entity by its email address; alternativesinclude the name of the entity and, where the attaching entity is aperson, just the initials of the person. Another example of a forwardedmessage with multiple attachments is shown below, where all headers inthe message are also shown.

Example Email Message

From Jane Smith Fri Dec 12 15:14:39 2003 X-Apparently-To:alice@iapdomain..com via 216.136.225.53; Fri, 12 Dec 2003 15:14:58 -0800Return-Path: <janes@iapdomain.com> Received: from 64.202.166.29 (HELOsmtpout-1-2d.secureserver.net) (64.202.166.29) bymta222.mail.scd.yahoo.com with SMTP; Fri, 12 Dec 2003 15:14:57 - 0800Received: (qmail 16195 invoked from network); 12 Dec 2003 23:14:58 -0000Received: from unknown (67.100.80.253) by smtpout-1-2d.secureserver.net(64.202.166.28) with ESMTP; 12 Dec 2003 23:14:58 -0000 Subject: FW: PicsDate: Fri, 12 Dec 2003 15:14:39 -0800 Message-ID:<002201c3c105$b84012f0$3201a8c0@Mike> MIME-Version: 1.0 Content-Type:multipart/mixed; boundary=“---- =_NextPart_000_0023_01C3C0C2.AA1CD2F0”X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: MicrosoftOutlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLEV6.00.2800.1165 Importance: Normal Content-Length: 434890 ForwardedMessage From: “John Doe” <johnd@iapdomain.com> To: janes@iapdomain.comSubject: Pics Date: Thu, 11 Dec 2003 08:21:36 -0800 Message-ID:<39A8F53E4B5F714EB75663F972770BDA08CC92@fnserver.doe.local>MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=“----=_NextPart_000_001D_01C3C0C2.A9F91E50” X-Priority: 3 (Normal)X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510X-Nonspam: Whitelist X-MimeOLE: Produced By Microsoft MimeOLEV6.00.2800.1165 Importance: Normal Attachment a.doc .jpg file, 750×563,63k X-AA_entity: “John Doe” <johnd@iapdomain.com> Attachment b.doc .jpgfile, 800×600, 66k X-AA_entity: “Jane Smith” <janes@iapdomain.com>

In the example above, the information on the attaching entity associatedwith a particular attachment is given in an “X-header” field, describedas X_AA_entity. Other optional message fields may be used, e.g. thosethat comply with a known messaging standard.

Still referring to FIG. 4, the message may be sent from the sourceclient 404 to a message transfer agent which in this embodiment is aSMTP server/relay 408. This can be done by way of a point of presence(PoP) 406 which gives the user access to the Internet and may beadministered by a commercial Internet access provider (IAP). The sourceuser may be a subscriber to the IAP and uses hardware (not shown) that,for example, may communicate with the PoP 406 via a dial-up connection,digital subscriber line (DSL) or other low level transmission link.

The message is further transferred over one or more hops, i.e. nodes ofan internet, before arriving at a recipient side mail transfer agent,here the SMTP relay 416. At the SMTP relay 416, the message may betransferred to a storage (not shown) and stored on behalf of therecipient. A recipient client program (or simply, client) 420 may thenreceive the message (e.g., by polling for new messages) from, forexample, an email box assigned to the recipient.

Note that in the embodiment depicted in FIG. 4, both the source andrecipient clients 404, 420 are aware of the associated attachmentcapability. In that case, neither the SMTP server/relay 408 nor the SMTPrelay 416 need be aware of the AA capability; it is up to the clients404, 420 to process and display information about the attaching entity.An example of the clients 404, 420 that may be modified to have the AAcapability is an email client program (e.g., NOTES software by LotusDevelopment Corp.).

To recap part of the discussion above in connection with FIG. 4, theclients 404, 420 were said to be “AA aware” in that each is inherentlycapable of interpreting a particular header field of a message asreferring to an attaching entity associated with an attachment in themessage. In other words, the recipient client 420 (as well as the sourceclient 404) have the needed program code (as provided by the publisherof the software that constitutes the client application) to interpretand properly display the associated attachment information to a user.Another embodiment of the invention is shown in FIG. 5, where the clientprograms are not capable of automatically interpreting the associatedattachment information. For example, the arbitrary client 504 may be aconventional Web browser that is used by the source user to access anemail box service to which he or she subscribes, e.g., YAHOO! Mail emailsolutions. The user in this case is a subscriber to a messaging service,and in particular one that provides the associated attachmentcapability. The user may request that a new message be created, via aWeb interface such as that provided by YAHOO! Mail email solutions, andmay specify an attachment to be inserted (according to conventionaltechniques). It is then up to the Internet service provider (ISP)network 509 that is hosting the email solution to recognize that theuser has requested a particular attachment, and in response to add aspecified field to the message to separately identify the source user asthe entity who requested that the attachment be inserted. Thismodification to the message can be performed by new software in the ISPnetwork 509 that will recognize the “sender” of the message (that willalso contain an attachment 124) as also being the attaching entity, andin response will add AA info field 128 to the message.

At the recipient side, an arbitrary client 520 (e.g., once again a Webbrowser that is used as a Web interface to the recipient user's emailaccount maintained by an Internet service provider such as YAHOO! Mailemail solutions) is used to access and display an “inbox”. Theassociated attachment messaging services added to the ISP network 509are responsible for providing the arbitrary client 520 with thenecessary data, so that the client 520 is able to receive informationabout the message (that includes an attachment), where this receivedinformation has been taken from a sender field and an AA info field ofthe message. For example, this received information may be presented tothe intended recipient of the message via Web site content that has beendownloaded by the arbitrary client 520.

Note that in the above described embodiments of FIGS. 4 and 5, althoughboth the source and recipient had a similar type of client program (forinstance in FIG. 4, both client programs were AA aware, whereas in FIG.5 neither client program was AA aware), the associated attachmentcapability may also be implemented in situations where only one of thesource and recipient clients is AA aware. In that case, the user thathas an arbitrary client (that is, one which is not AA aware) may need tobe a subscriber to an AA messaging service so that his arbitrary clientcan properly display to the user any associated attachment informationthat may have been inserted into a particular message.

Referring back to FIG. 1, the attaching entity may be identified to auser by for example an email address being continuously displayed to theuser, below the filename of the attachment, as shown in FIG. 1. Analternative however is to display this information as a “mouse-over”.This is illustrated in FIG. 6. Whenever a cursor 608 is positioned overthe displayed filename field 26 of an attachment, a pop-up 610 appears,to identify the attaching entity. The pop-up 610 disappears once thecursor has been moved off the filename field 26. In another embodiment,information about the attaching entity is displayed using a collapsedown—collapse up feature as depicted in FIG. 7. Each attachment may beassociated with a separate triangular icon 704, 708 that can beclicked-on by the user, to collapse down and collapse up the informationabout the associated attachments.

FIGS. 8 and 9 show additional examples of displaying a message withassociated attachment capability. In FIG. 8, the message is displayedwith an attachment section 804 that is collapsed. In this example, thereare three attachments as shown. Upon an end user clicking the expandicon 808, an expanded view appears as shown in FIG. 9. Note theadditional data that is displayed for each of the three attachments,namely the name of the attaching entity and the date the attachment wascreated by its author. Alternatively, this additional data may includeother types of “meta info” that can be associated with the attachingentity. Not all of this meta info need be displayed, however.

FIGS. 8 and 9 also show another attachment section 812 that may be usedinstead of the collapsible section 804. In this case, the associatedattachment information, e.g. the name of the attaching entity, isautomatically displayed next to the name of its respective attachmentwhen the message is opened by the end user, such that there is no needto click to expand the view (as with the section 804).

The user interface in FIGS. 8 and 9 may be a Web-based client that isused to view and manage an email services account of an end user. Theservice may be one that combines conventional email storage andtransmission with the fax/voice-to-email capability offered by j2 GlobalCommunications. The user is identified by name and by an inboundfax/voice number in the section 820. A section 824 displays icons fordifferent folders, one of which is INBOX (highlighted). Higher levelactions such as setting preferences of the user interface, managing thefolders, customer support, and the message inbox section may be takenusing another set of icons in section 826. Finally, storage detailsregarding the email services account are displayed in section 828.

The embodiments of the invention described above may be provided as acomputer program product or software which may include a machine orcomputer-readable medium having stored thereon instructions which may beused to program a computer (or other electronic devices) to perform aprocess according to an embodiment of the invention. In otherembodiments, operations might be performed by specific hardwarecomponents that contain microcode, hardwired logic, or by anycombination of programmed computer components and custom hardwarecomponents.

To summarize, various embodiments of a modification to a messagingprotocol, for better dealing with attachments, have been described. Inthe foregoing specification, the invention has been described withreference to specific exemplary embodiments thereof. It will, however,be evident that various modifications and changes may be made theretowithout departing from the broader spirit and scope of the invention asset forth in the appended claims. For instance, although the AA infofield has been illustrated in several example email messages ascontaining only information that identifies the attaching entity, thisfield may be used to contain additional information such as a filenamefor the attachment, and a time stamp (as to for example the time and/ordate when the attachment was inserted into the message or when theattachment was created by its author). The specification and drawingsare, accordingly, to be regarded in an illustrative rather than arestrictive sense.

1. An article of manufacture comprising: a computer-readable mediumhaving stored thereon instructions that program a computer to (a) insertinto a first field and a second field of a message, that is to beprocessed according to an electronic messaging protocol, informationthat identifies a sender and a recipient of the message, respectively,(b) insert into the message an attachment pursuant to a request from anattaching entity, and (c) insert into a third field of the message,which is associated with the attachment, a unique property of theattaching entity, wherein in the message, the attachment is outside thefirst, second, and third fields.
 2. The article of manufacture of claim1 wherein the electronic messaging protocol is an email protocol.
 3. Thearticle of manufacture of claim 1 further comprising instructions storedin the medium that program a computer to send the message, including theattachment and the first, second and third fields, to a message transferagent, the agent being a node within a plurality of networksinterconnected with one or more routers.
 4. The article of manufactureof claim 3 wherein the insert and send operations are to be performed byone of (a) a source user agent and (b) a client program of the sender.5. The article of manufacture of claim 1 wherein the message is aforwarded message that includes information that identifies one or moreprior senders.
 6. The article of manufacture of claim 1 wherein themessage includes (i) a further attachment from a prior sender and (ii)information that separately identifies the prior sender as a furtherattaching entity who had requested that the further attachment beinserted.
 7. An article of manufacture comprising: a computer-readablemedium having instructions stored thereon that program a computer toprocess a message that has been delivered in accordance with a messagingprotocol for networks interconnected with one or more routers, whereinthe message includes (a) an attachment, (b) a first field thatidentifies a sender, (c) a second field that (i) identifies an entitywho requested that the attachment be inserted and (ii) is associatedwith the attachment, and (d) a third field that identifies a recipient,wherein the message is to be processed so as to present information fromthe attachment and the first and second fields to the recipient.
 8. Thearticle of manufacture of claim 7 wherein the presented information isdisplayed in a graphical user interface window and comprises (i) afilename of the attachment, (ii) identification of the entity who hadrequested the attachment be inserted as obtained from the second field,and (iii) identification of the sender as obtained from the first field.9. The article of manufacture of claim 8 wherein the instructions causethe identification of the entity, who had requested that the attachmentbe inserted, to be displayed as a mouse-over whenever a pointer in thewindow is positioned over the displayed filename of the attachment. 10.The article of manufacture of claim 8 wherein the instructions cause theidentification of the entity, that had requested that the attachment beinserted, to disappear from the window when the displayed filenamecollapses back up.
 11. The article of manufacture of claim 7 wherein theinstructions cause the message to be further processed so as to presentfurther information to the recipient from (i) a further attachment inthe message that is from a prior sender, and (ii) a field in themessage, separate from the further attachment, that identifies a furtherattaching entity who inserted the further attachment.
 12. The article ofmanufacture of claim 7 wherein the instructions cause the message to befurther processed so as to present further information to the recipientabout a prior sender identified in the message.
 13. An article ofmanufacture comprising: a computer-readable medium having stored thereoninstructions that program a computer to (a) process a message from aclient program of a subscriber to a communications service, wherein themessage is to be delivered according to a messaging protocol for aplurality of networks interconnected with one or more routers, andwherein the message is to include an attachment, a first field thatidentifies a sender as the subscriber, and a destination field thatidentifies a recipient of the message, and (b) add a second field to themessage that (i) identifies an entity who requested that the attachmentbe inserted into the message and (ii) is associated with the attachment,wherein in the message, the attachment is outside the first, second, anddestination fields.
 14. The article of manufacture of claim 13 whereinthe instructions are to program a server network to perform theprocessing and adding operations.
 15. The article of manufacture ofclaim 13 wherein the communication service is an email service thatprovides email box storage for the subscriber.
 16. An article ofmanufacture comprising: a computer-readable medium having stored thereoninstructions that program a computer to (a) receive information from aheader portion of a message, the message includes the header portion andan attachment that was inserted pursuant to a request from an attachingentity, and wherein the received information identifies a sender of themessage and, separately, identifies and associates the attaching entitywith the attachment, and (b) present the received information to arecipient of the message.
 17. The article of manufacture of claim 16wherein the received information to be presented includes identificationof the sender, date sent, subject, and an attachment file name, to bedisplayed on a screen, and wherein a unique property of the attachingentity, obtained from the received information, is to be displayed inresponse to the recipient selecting one of the attachment file name andan attachment symbol associated with the message.
 18. The article ofmanufacture of claim 17 wherein the received information to be presentedfurther includes message size.
 19. The article of manufacture of claim16 wherein the received information is to be presented to the recipientvia a client email program.
 20. The article of manufacture of claim 16wherein the received information is to be presented to the recipient viaa client Web browser interface to an email box service.
 21. Acomputer-implemented method for communicating, comprising: creating amessage having a first field and a second field that contain informationthat identifies a sender and a recipient of the message, respectively,and an attachment added pursuant to a request from an attaching entity;and inserting into a third field of the message, which is associatedwith the attachment, a unique property of the attaching entity, whereinin the message, the attachment is outside the first, second, and thirdfields.
 22. The method of claim 21 wherein the message is an emailmessage that complies with a MIME protocol.
 23. The method of claim 21wherein the unique property of the attaching entity is an email address.24. A computer-implemented method for communicating, comprising:receiving a message that has been delivered by an electronic messagingprotocol for networks interconnected by routers, the message includes anattachment added by an attaching entity, a first header field thatidentifies a sender of the message, a second header field associatedwith the attachment and that identifies the attaching entity, and athird header field that identifies a recipient of the message; andpresenting information taken from the first and second header fields tothe recipient.
 25. The method of claim 24 wherein the second headerfield is an X-header field.
 26. The method of claim 24 wherein thereceiving and presenting are performed by a computer running a clientprogram that is inherently capable of interpreting the second headerfield of the message as referring to an attaching entity associated withthe attachment.
 27. The method of claim 24 wherein the receiving andpresenting are performed by a computer running a client program thatfurther receives instructions, from a provider of messaging services whoprocessed the message, for interpreting the second header field of themessage as referring to an attaching entity associated with theattachment.
 28. The method of claim 24 wherein the presenting isperformed via Web site content that is downloaded by the recipient. 29.The method of claim 28 wherein the recipient is a paying subscriber to amessaging service from a provider who processed the message.
 30. Themethod of claim 29 wherein the messaging service includes hostingstorage of the message.
 31. The method of claim 24 wherein the messagewas forwarded.
 32. The method of claim 31 wherein the message includes afurther attachment, and a further header field that is associated withthe further attachment and identifies a further attaching entity whoadded the further attachment.
 33. The method of claim 32 furthercomprising: presenting information taken from the message and thefurther header field to the recipient, that identifies a further senderand that includes a unique property of the further attaching entity. 34.The method of claim 33 wherein said presenting information taken fromthe message and the further header field comprises: displaying theunique property of the further attaching entity on a screen adjacent toan icon for the further attachment.
 35. The method of claim 24 whereinsaid presenting information taken from the first and header fieldscomprises: displaying on a screen and in a single line sender name, datesent, subject, and an attachment symbol.
 36. The method of claim 35further comprising: displaying a unique property of the attaching entityobtained from the second header field, in response to the attachmentsymbol being selected.